Reserved ROM space for storage of operating system drivers

ABSTRACT

Disclosed is a system and related method for providing operating system drivers during installation of an operating system. In particular, the operating system drivers, that are not available with the operating system itself, are stored in unreserved ROM space. At an appropriate time during installation of the operating system, any needed or necessary drivers are copied from the ROM.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[0001] Not applicable.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is related to application Ser. No. ______(Att'y. Docket No. 1662-41000) entitled “Semi-Persistent, RelocatableRAM-Based Virtual Floppy Disk for Providing Operating System Drivers,”filed concurrently herewith.

BACKGROUND OF THE INVENTION

[0003] 1. Field of the Invention

[0004] The present invention relates generally to loading operatingsystems on computer or server systems. More particularly, the preferredembodiments of the present invention are directed to insuring theavailability of operating system drivers during the operating systeminstallation process. More particularly still, the preferred embodimentsof the present invention are directed to storing operating systemdrivers in unreserved ROM and making those drivers available during theinstallation of the operating system.

[0005] 2. Background of the Invention

[0006] One of the first functions that must be performed before acomputer or server system is ready for operation is installation of theoperating system. In early computer systems, this involved loading theDisk Operating System (DOS) to make available the then-familiar “C:>”prompt. For many years, DOS was the predominant operating system, evenif another form of Graphical User Interface (GUI) was used. In recentyears, however, software companies such as Microsoft, Inc. have createdand are disseminating software that is not DOS-based. For example,Windows NT is an operating system and GUI in one package. Likewise,Windows 2000 is an operating system and GUI. These new systemscommunicate with hardware within the computer system by way of operatingsystem or hardware drivers, rather than through traditional basicinput/output system (BIOS) routines. During the process of installingthese operating systems/user interfaces, it is required that properdrivers are installed for the hardware resident in the computer system.

[0007] Although several software manufacturers make operating systems,e.g., Linux, Novell, and Windows, the problem of installing correctoperating system drivers is inherent in each package. In particular,software manufacturers typically bundle, along with the programs thatmake up their operating system, every operating system driver availableas of the release date. However, there may be many months or even yearsbetween the release of the operating system and manufacture of thehardware devices within the computer system. Thus, it is inevitable thedrivers are needed that are not included with the operating system.Installing an operating system driver other than one of the driversincluded with the operating system software typically involves findingthe appropriate driver, either on the internet or on a CD ROM includedwith the computer system. This driver is then typically copied or“punched-out” to a floppy drive (on a second computer as the CD ROM onthe computer involved in the installation process is most likely notoperational). The floppy disk drive including the required operatingsystem driver is then inserted into the floppy drive unit of theaffected computer at the appropriate time during the installationprocess.

[0008] While it is possible to install the correct operating systemdriver in this manner, it is seen from the above discussion that this isa complicated procedure. In the context of installing the operatingsystem onto a server in a rack of servers, the situation gets morecomplex as each individual server may not have its own floppy drive; butrather, keyboard, video and floppy drive access may only be availableacross a communication bus.

[0009] Thus, what is needed in the art is a way to provide, during theoperating system installation, operating system drivers withoutrequiring the user to punch-out floppy disk drives or search theinternet via other computer devices to find the necessary drivers.

BRIEF SUMMARY OF THE INVENTION

[0010] The problems noted above are solved in large part by a system andrelated method where operating system drivers necessary or needed forinstallation of the operating system, yet not provided with theoperating system (possibly because the driver was developed afterrelease of the operating system software) are preferably stored inunreserved ROM space in the computer system along with the basicinput/output system (BIOS) routines. Operating system drivers providedin this manner are thus copied from the ROM at the appropriate timeduring the operating system installation procedure.

[0011] Storing the operating system drivers in the unreserved ROM spacehas several facets in the preferred embodiments. In one implementation,the operating system drivers are appended to the end of the BIOSroutines within each redundant portion of the ROM. In this way, thereare two sets of duplicate operating system drivers. In a second aspectof storing the operating system drivers, the ROM is divided intoredundant and non-redundant portions. The BIOS programs are stored, in aredundant fashion, in the redundant portion of the ROM, and theoperating system drivers are stored in the non-redundant portion of theROM. In a third aspect of how to store these operating system drivers, asingle ROM is provided having a single copy of the BIOS, and a singlecopy of all provided operating system drivers. Once the necessaryoperating system drivers have been provided, a utility programpreferably overwrites the operating system drivers on the ROM with asecond copy of the BIOS program, thereby providing redundancy of theBIOS firmware.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] For a detailed description of the preferred embodiments of theinvention, reference will now be made to the accompanying drawings inwhich:

[0013]FIG. 1 shows a computer system of the preferred embodiment;

[0014]FIG. 2 shows, in block diagram form, the contents of a ROM of theprior art;

[0015]FIG. 3 shows, in block diagram form, the contents of a ROM of oneof the embodiments of the present invention;

[0016]FIG. 4 shows, in block diagram form, the contents of a ROM of oneembodiment of the present invention;

[0017]FIG. 5 shows, in block diagram form, the contents of a ROM of oneembodiment of the invention, both before and after copying of theoperating system drivers;

[0018]FIG. 6 shows, in block diagram form, the contents of a ROM of oneembodiment of the invention having multiple floppy images containedthereon; and

[0019]FIG. 7 shows a virtual memory map of the preferred embodiments.

NOTATION AND NOMENCLATURE

[0020] Certain terms are used throughout the following description andclaims to refer to particular system components. As one skilled in theart will appreciate, computer companies may refer to a component bydifferent names. This document does not intend to distinguish betweencomponents that differ in name but not function.

[0021] In the following discussion and in the claims, the terms“including” and “comprising” are used in an open-ended fashion, and thusshould be interpreted to mean “including, but not limited to . . . ”.Also, the term “couple” or “couples” is intended to mean either anindirect or direct electrical connection. Thus, if a first devicecouples to a second device, that connection may be through a directelectrical connection, or through an indirect electrical connection viaother devices and connections.

[0022] Throughout the specification and claims, the term read onlymemory (ROM) refers to integrated circuit memory devices. If other typesof read only memory devices are the focus of the discussion, those willbe referred to directly, e.g., compact disk ROM (CDROM) and the like.Thus, the term ROM, unless specifically limited, may be programmableread only memory (PROM), erasable programmable read only memory (EPROM),and the variants of EPROM such as ultra-violet erasable programmableread only memory (UVPROM) and electrically erasable programmable readonly memory (EEPROM).

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] Referring now to FIG. 1, computer system 100 in accordance withthe preferred embodiment comprises at least one CPU 10. Inasmuch ascomputer system 100 is preferably a server system, the computer system100 may comprise multiple CPUs 10A, 10B, 10C, 10D arranged in aconfiguration where parallel computing may take place. The CPU array 10couples to a main memory array 12 and a variety of other peripheralcomputer system components through an integrated host bridge logicdevice 14. The CPU array 10 may comprise, for example, a plurality ofPentium® III microprocessors. It should be understood, however, thatcomputer system 100 could include other alternative types and numbers ofmicroprocessors. Additionally, other architectures could be used ifdesired. Thus, the computer system may implement other busconfigurations and bus bridges in addition to, or in place of, thoseshown in FIG. 1.

[0024] The main memory array 12 preferably couples to the host bridgelogic 14 through a memory bus 16, and the host bridge logic 14preferably includes a memory control unit (not shown) that controlstransactions to the main memory 12 by asserting the necessary controlsignals during memory accesses. The main memory 12 functions as theworking memory for the CPUs 10 and generally includes a conventionalmemory device or array of memory devices in which program instructionsand data are stored. The main memory array 12 may comprise any suitabletype of memory such as Dynamic Random Access Memory (DRAM) or any of thevarious types of DRAM devices such as Synchronous DRAM (SDRAM), ExtendedData Output DRAM (EDO DRAM), or Rambus™ DRAM (RDRAM).

[0025] Inasmuch as computer system 100 is preferably a server system,the computer system 100 may not have a dedicated display device. If thecomputer system did have a dedicated display device, such a system couldbe implemented by coupling a video driver card to the host bridge 14 byway of an Advanced Graphics Port bus or other suitable type of bus.Alternatively, the video driver card could couple to the primaryexpansion bus 18 or one of the secondary expansion buses, for example,the PCI bus 20. If the computer system had a dedicated display device,the video driver or graphic controller would couple to a display device.That display may comprise any suitable electronic display device uponwhich any image or text can be represented.

[0026] The computer system 100 preferably comprises a second bridgelogic device 22 that bridges the primary expansion bus 18 to varioussecondary buses including a low pin count (LPC) bus 24 and a peripheralcomponent interconnect (PCI) bus 20. In accordance with the preferredembodiment, the bridge device 36 is an Input/Output Controller Hub (ICH)manufactured by Intel Corporation. Although the ICH 22 of FIG. 1 isshown only to support the LPC bus 24 and the PCI bus 20, various othersecondary buses may be supported by the ICH 22. In the preferredembodiment shown in FIG. 1, the primary expansion bus 18 comprises aHub-link bus which is a proprietary bus of the Intel Corporation.However, computer system 100 is not limited to any particular type ofprimary expansion bus, and thus other suitable buses may be used.

[0027] Referring still to FIG. 1, a firmware hub 26 couples to the ICH22 by way of the LPC bus 24. The firmware hub 26 preferably comprisesRead Only Memory (ROM) which contains software programs executable bythe CPU array 10. The software programs preferably include programs toimplement basic input/output system (BIOS) commands, and instructionsexecuted during and just after Power On Self Test (POST) procedures.

[0028] A Super Input/Output controller 28 couples to the ICH 22 andcontrols many system functions including interfacing with various inputand output devices such as keyboard 30. The Super I/O controller 28 mayfurther interface, for example, with a system pointing device such as amouse 32, various serial ports (not shown) and floppy drives (notshown). The Super I/O controller is often referred to as “super” becauseof the many I/O functions it may perform.

[0029] Also shown in the computer system 100 of FIG. 1 are three arraycontrollers 50A, 50B, 50C coupled to the ICH 22 by way of the PCI bus20. Each array controller 50 couples to a plurality of hard drives 52A,52B, 52C. Thus, the array controller 50 preferably performs data reads,data writes and other necessary data manipulation to implement aredundant array of independent devices (RAID) system. It will beunderstood that while FIG. 1 shows only three array controllers 50,computer system 100 may support any number of these controllers. It mustbe understood however that the invention is not limited to computersystems having multiple CPUs or implementing RAID systems; rather, thepreferred embodiments apply equally to all types of computer systems.

[0030] The preferred embodiments of the present invention address how toprovide operating system drivers during the operating systeminstallation process. In particular, the preferred embodiments of thepresent invention provide necessary operating system drivers by placingor storing those drivers in the ROM or firmware hub 26. Preferably,required or needed operating system drivers may simply be copied fromthose versions resident in the system ROM 26 during the operating systeminstallation procedure.

[0031] In computer systems requiring high availability and reliability,e.g., server systems, it is common to have multiple copies of the BIOSfirmware or programs stored in the system ROM 26. FIG. 2 shows a priorart technique for having multiple copies that simply involves burningtwo copies of the BIOS programs onto the ROM 26. In particular, FIG. 2shows two copies of the BIOS, with the first copy occupying the first512 kilobytes of the ROM, and the second copy occupying the second 512kilobytes of the one megabyte ROM. As one of ordinary skill in the artis aware, most computer and server systems have a smaller ROM known as a“boot-block” ROM (not shown) that is responsible for selecting which ofthe multiple copies of the BIOS will be loaded during the POSTprocedure.

[0032] Placing operating system drivers in the ROM 26 may take manyforms. FIG. 3 shows one embodiment in which the operating system drivers(labeled OSD in the drawing) are placed within each redundant section ofthe ROM 26. At the appropriate time during the operating systeminstallation procedure, either or both of the drivers stored on the ROM26 would be made available for copying and use by the operating system.A preferred embodiment for making those operating system driversavailable is discussed more fully below.

[0033] Operating system drivers range in complexity, and therefore rangein size, with some drivers approaching 100 kilobytes or more. In asituation where the drivers are large, the implementation shown in FIG.3 would not be desirable inasmuch as the operating system drivers wouldoccupy significant space in the ROM (especially given the duplication).Conversely, if the operating system drivers to be provided on the ROM 26are relative small, the implementation exemplified in FIG. 3 may beacceptable.

[0034] Where the operating system drivers are large, or a number ofdrivers must be provided, the preferred embodiments provide for storingthose operating system drivers in a non-redundant area of the ROM 26.FIG. 4 shows an implementation where a larger, preferably two megabyte,ROM is used. Preferably, the ROM is divided up into redundant 30 andnon-redundant 32 space. In FIG. 4, the redundant space is shown tooccupy the first one megabyte of the ROM 26, and the non-redundantspace, containing the operating system drivers, is shown to occupy thesecond one megabyte. It must be understood, however, that division ofthe ROM 26 of FIG. 4 is only exemplary, and the storage space of the ROM26 may be divided in any convenient way. Using the implementationexemplified in FIG. 4, a boot-block program stored on a boot-block ROM(not shown), selects one of the two BIOS firmware copies stored in theredundant area 30 of the ROM 26. Thereafter, and at the appropriate timeduring the operating system installation procedure, the operating systemdrivers located in the non-redundant area 32 of the ROM are madeavailable.

[0035] In the exemplary implementation of storing operating systemdrivers on the ROM 26 as shown in FIG. 4, the size of the ROM 26 wasincreased from one megabyte to two megabytes, such that the duplicatecopies of the BIOS and the operating system drivers could reside on asingle ROM device. However, increasing the size of the ROM 26 alsoincreases system cost. For this reason, some manufacturers may not wantto spend the additional money to provide the larger ROMs, but still maywant to provide redundant copies of the BIOS and also provide copies ofthe operating system drivers on the ROM.

[0036]FIG. 5 shows one possible implementation for providing both theredundant BIOS and the operating system drivers on the ROM. Inparticular, the upper ROM 26 is shown to have a single copy of the BIOSprograms, as well as a copy of the operating system drivers. Preferably,the ROM 26 has this configuration as it leaves the factory and duringthe operating system installation procedure. The program stored in theboot block ROM (not shown) determines whether the ROM contents are BIOSprograms or operating system drivers by use of signatures in the BIOSfirmware that identify the programs. Preferably, once the operatingsystem drivers have been provided during installation of the operatingsystem, a utility program copies the BIOS, provided only innon-redundant fashion initially, to the second half of the ROM 26. Bycopying the BIOS over the operating system drivers, a redundant BIOSsystem is provided, as shown in the lower ROM 26 of FIG. 5. While thisimplementation provides both the redundant BIOS, after operating systeminstallation, and also provides operating system drivers on the ROM, theoperating system drivers are overwritten and thus will not be availableif the operating system must be installed again.

[0037] While there may be many ways to implement making the operatingsystem drivers stored on the ROM 26 available during the operatingsystem installation procedure, the Applicants now endeavor to describethe preferred method. Making the operating system drivers available hasthree aspects in the preferred embodiment: 1) providing the latestdrivers for each major operating system; 2) making those driversavailable to the user during installation of the operating system by useof a virtual disk drive; and 3) providing those operating system driversin a virtual drive scheme with the system drivers residing in RAM.

[0038] As discussed in the Background section, there are many availableoperating systems for computers in the marketplace, e.g., Linux(manufactured by Red Hat Software), Novell (manufactured by NovellIncorporated), Windows 2000 (manufactured by Microsoft Inc.). For aparticular piece of hardware in the system, e.g., an array controller 50(FIG. 1), each operating system may require a different driver. This maybe due in part to differences in protocols with regard to interfacingwith the operating system, but may also be caused merely by differencesin file structures between operating systems. Stated otherwise, a driverfor operating an array controller 50 in a Windows 2000 environment (FATfile system) may not be suitable for use in a Linux environment (2×72file system). Thus, in the preferred embodiment, if drivers need to beincluded on the system ROM 26, preferably drivers for each of the majoroperating systems are provided. Considering that there may be an arrayof devices for which the latest operating system driver may be provided,it is easily seen that the amount of space on the ROM 26 required tostore each driver for each hardware system may become rather large. Inthis regard, the implementation shown in FIG. 4 for dividing the ROM 26into a redundant 30 and non-redundant 32 portion is the preferredimplementation.

[0039]FIG. 6 exemplifies the situation where multiple sets of operatingsystem drivers are provided. In particular, FIG. 6 shows that thenon-redundant 32 space of the ROM 26 contains several sets of drivers,in the exemplary system, a set of Linux drivers 34, Novell drivers 36and Windows drivers 38. It must be understood that providing theseparticular drivers is only exemplary, and any number of drivers for anynumber of operating systems may be provided and still be within thecontemplation of this invention. Further, FIG. 6 implies that theoperating system drivers occupy the entire non-redundant 32 space of theROM 26; however, this need not necessarily be the case, and any or allof the non-redundant 32 space may be used to store the operating systemdrivers.

[0040] In the preferred embodiment described above, a set of operatingsystem drivers (34, 36, 38 of FIG. 6), which may alternatively bereferred to as floppy images, are provided in the ROM 26. These multiplesets of operating system drivers are provided to account for the factthat a manufacturer may not know at the time of building the computersystem what operating system will be installed thereon. Since multiplesets of operating system drivers are preferably provided, there shouldbe a method of providing the correct drivers for the particularoperating system. In the preferred embodiments, making available thecorrect operating system drivers for the operating system is preferablyaccomplished by a BIOS setup parameter and a modification to thestandard disk access routine known as Interrupt 13h.

[0041] In the preferred embodiment the BIOS setup routines are modifiedto contain a field where a user, when making an initial setup of theBIOS, selects which operating system is to be installed on the computeror server. It must be understood that this selection in the BIOS is nota part of the operating system installation procedure; but rather, ismerely a mechanism to inform the BIOS which operating system is to beinstalled. Preferably, the BIOS uses this information to select anappropriate floppy image having a set of operating system drivers fromthe images stored in the non-redundant 32 space of the ROM 26. Forexample, if a user selects from the BIOS setup screen that Windows 2000will be the operating system for the computer, the BIOS then makesavailable, in a manner described more fully below, the floppy imagecontaining Windows operating system drivers 38 (see FIG. 6).

[0042] While there may be many ways to make the particular operatingsystem drivers available during the operating system installationprocess, in the preferred embodiments, those drivers are made availableto the user and to the operating system installation procedure by havingthem reside on a virtual floppy drive or virtual disk drive. Moreparticular, in the preferred embodiment, the Interrupt 13h BIOS callsfor performing disk drive activities are preferably implemented suchthat the operating system drivers (either all of them or just theappropriate drivers for the particular operating system) stored on theROM 26 appear to reside on a disk drive. Because the files are notactually stored on a floppy disk, this is known as creating a virtualdrive. As mentioned above, the user preferably selects in a BIOS setupscreen which operating system is to be installed on the computer system,and based on that selection, preferably only the drivers appropriate forthe selected operating system are made available in this virtual drivemethod. One of ordinary skill in the art is familiar with Interrupt 13hBIOS calls, how to implement them, and now understanding how to providedrivers in this way, could modify the standard programs to provide thisvirtual drive feature.

[0043] More particularly still, in the preferred embodiment, selecting aparticular operating system to be installed preferably sets anenvironment variable in a non-volatile memory. This non-volatile memorycould be non-volatile RAM (NVRAM), or may be written directly to the ROM26, which in the preferred embodiment is electrically erasableprogrammable read only memory (EEPROM). Regardless of the location ofthe environment variables, by selecting an operating system, theenvironment variables preferably point to a floppy image havingoperating system drivers appropriate for that operating system. Duringthe installation process, before the operating system is installed, diskservices are provided by the BIOS. Thus, during installation, theInterrupt 13h services preferably are adapted to show the appropriateoperating system drivers, indicated by the environment variables, asresiding on a disk drive. Thus, drivers needed for correct setup duringthe operating system installation process are then available as if theyhad been copied to a floppy and inserted in a disk drive in the system.Using the preferred embodiment alone, it is then possible to provide theoperating system drivers during the operation system installationprocess by informing the installation program of the need to use driversdifferent than those provided with the operating system, and pointingthat operating system software to the virtual drive. However, nowunderstanding how to make available software drivers in the manner ofthe preferred embodiment, one of ordinary skill in the art could easilymodify the installation program to automatically search for and usedrivers resident on virtual drives with little or not user input.

[0044] Referring now to FIG. 7, there is shown an exemplary virtualaddress space or virtual memory map for the computer or server system ofthe preferred embodiment. As one of ordinary skill in the art is aware,the ROM 26 contents are typically mapped in the virtual address space toa location having addresses just below the four gigabyte addressablespace. In this way, the system devices wishing to access the ROMcontents need only know the addresses of those ROM contents in thevirtual address space. As exemplified in FIG. 7, the virtual addressspace includes not only the floppy images having the operating systemdrivers 34, 36 and 38, but also includes all the addressable space forthe random access memory (RAM), the RAM area. Thus, in the preferredembodiment, when the user selects the particular operating system to beinstalled in the BIOS setup screens, the BIOS preferably updates anenvironment variable which points, in the virtual address space, to theoperating system drivers appropriate for that operating system to beinstalled. Sometime thereafter, when performing disk accesses using theBIOS subroutines, the installation process requests an operating systemdriver from a virtual drive. The Interrupt 13h services provide theoperating system drivers available at the location indicated by theenvironment variables as if those drivers were provided on an actualfloppy drive.

[0045] It is noted, however, that the mapping of the possible operatingsystem drivers 34, 36 and 38 are within the same virtual address spaceas the random access memory (FIG. 7). In another aspect of theinvention, information and data may be provided to the operating systemby use of a virtual disk drive, where the contents of that virtual diskdrive resides in the RAM area 62 portion of the virtual memory ratherthan one of the operating system drivers, again within the virtualaddress space. Data and programs placed in a virtual drive with itscontents stored in RAM would be semi-persistent, meaning that the datawould survive and be available after a warm boot, for example an warmboot initiated by an Interrupt 19h.

[0046] While creating a virtual disk drive resident in RAM andaccessible through BIOS interrupts was developed in the context ofproviding operating system drivers during operating system installationprocedures, any data or programs which need to be made available in asemi-persistent manner may be provided in this way, and still be withinthe contemplation of the invention.

[0047] The above discussion is meant to be illustrative of theprinciples and various embodiments of the present invention. Numerousvariations and modifications will become apparent to those skilled inthe art once the above disclosure is fully appreciated. For example, thepreferred embodiments have been described with regard to placing theoperating system drivers on the same ROM as the BIOS programs; however,the ROM provided in the computer system could be a ROM array comprisingseveral individual ROM devices, and the operating system software couldreside on any or all of the ROM devices, and still be within thecontemplation of this invention. Further, providing operating systemdrivers in the manner described herein was developed in the context ofserver systems having multiple microprocessors and multiple hard drivesimplementing RAID systems; however, one of ordinary skill in the art,now understanding how to implement and use the preferred embodiments,could easily apply the preferred embodiments to stand alone computersystems having only a single microprocessor and single hard drive.Further, the systems and methods described herein are equally applicableto most computing devices such as hand-held computing devices, portablecomputers, process control systems, and the like. It is intended thatthe following claims be interpreted to embrace all such variations andmodifications.

What is claimed is:
 1. A computer system comprising: a CPU; a mainmemory array; a first bus bridge coupling the CPU and main memory array;a primary expansion bus; a secondary expansion bus; a second bus bridgecoupling the primary and secondary expansion bus; a read only memory(ROM) coupled to the secondary expansion bus, where the ROM stores afirst set of basic input output system (BIOS) programs, and furtherwhere the ROM stores a first set of operating system drivers; andwherein at least one operating system driver of the first set ofoperating system drivers is read from the ROM during installation of anoperating system for the computer system.
 2. The computer system asdefined claim 1 wherein the ROM further comprises: said first set ofBIOS programs associated with the first set of operating system drivers;a second set of BIOS programs; and a second set of the of the operatingsystem drivers associated with the second set of BIOS programs.
 3. Thecomputer system as defined in claim 2 wherein the first and second setsof BIOS programs are substantially identical.
 4. The computer system asdefined in claim 2 wherein the first and second sets of operating systemdrivers are substantially identical.
 5. The computer system as definedin claim 2 wherein the ROM further comprises an electrically erasableprogrammable read only memory.
 6. The computer system as defined inclaim 1 wherein the ROM further comprises: a redundant portion; anon-redundant portion; wherein the redundant portion of the ROM storesthe first set of BIOS programs and a second set of BIOS programs; andwherein the non-redundant portion of the ROM stores the first set ofoperating system drivers.
 7. The computer system as defined in claim 6wherein the first and second set of BIOS programs are substantiallyidentical.
 8. The computer system as defined in claim 6 wherein the ROMfurther comprises an electrically erasable programmable read onlymemory.
 9. The computer system as defined in claim 1 further comprising:wherein the ROM further comprises an electrically erasable programmableread only memory (EEPROM); and wherein the EEPROM stores twosubstantially identical copies of the BIOS programs after installationof the operating system.
 10. In a computer system a having read onlymemory (ROM), a method of storing hardware drivers to be installedduring installation of an operating system, the method comprising:storing in the ROM device a basic input output system (BIOS) program;and storing in the ROM the hardware drivers.
 11. The method of storinghardware drivers as defined in claim 10 further comprising: dividing theROM into a redundant and non-redundant portions; storing the BIOSprogram in the redundant portion of the ROM; storing a second BIOSprogram in the redundant portion of the ROM; and storing the hardwaredrivers in the non-redundant portion of the ROM.
 12. The method ofstoring hardware drivers as defined in claim 11 wherein the BIOS programand the second BIOS program are substantially the same.
 13. The methodof storing hardware drivers as defined in claim 10 further comprising:storing a first copy of the BIOS program in the ROM; storing a firstcopy the hardware drivers in the ROM associated with the first copy ofthe BIOS program; storing a second copy of the BIOS program in the ROM;and storing a second copy of the hardware drivers in the ROM associatedwith the second copy of the BIOS program.
 14. The method of storinghardware drivers as defined in claim 10 further comprising: storing theBIOS program being a first BIOS program in the ROM, the ROM being anelectrically erasable programmable read only memory (EEPROM); storingthe hardware drivers in the EEPROM; copying one or more hardware driversfrom the EEPROM; erasing the hardware drivers from the EEPROM after theone or more hardware drivers have been copied; and flashing a secondBIOS program to the EEPROM in place of the hardware drivers.
 15. Themethod of storing hardware drivers as defined in claim 14 wherein thesecond BIOS program is substantially the same as the first BIOS program.16. In a computer system having a read only memory (ROM) device storingbasic input output system (BIOS) programs, a method of installing anoperating system requiring an operating system driver on the computersystem comprising: supplying the operating system driver during theinstallation of the operating system by copying the operating systemdriver from the ROM device.
 17. The method of installing an operatingsystem requiring an operating system driver as defined in claim 16further comprising supplying the operating system driver from the ROMbeing an electrically erasable programmable read only memory.
 18. Acomputer system comprising: a microprocessor; a main memory array; afirst bus bridge coupling the microprocessor and main memory array; aprimary expansion bus; a secondary expansion bus; a second bus bridgecoupling the primary and secondary expansion bus; a read only memory(ROM) coupled to the secondary expansion bus; and wherein the ROMfurther comprises: a redundant portion; a non-redundant portion; whereinthe redundant portion of the ROM stores the first set and a second setof BIOS programs; and wherein the non-redundant portion of the ROMstores the operating system drivers; wherein at least one of theoperating system drivers is read from the ROM during installation of anoperating system for the computer system.
 19. The computer system asdefined in claim 18 wherein the first and second sets of BIOS programsare substantially the same.
 20. The computer system as defined in claim19 wherein the ROM further comprises an electrically erasableprogrammable read only memory.
 21. In a computer system having anelectrically erasable programmable read only memory (EEPROM) coupled toa bridge logic device, a method of storing operating system drivers foruse during installation of an operating system, the method comprising:dividing the EEPROM into a redundant and non-redundant portions; storingin the redundant portion of the EEPROM a first set of basic input outputsystem (BIOS) programs and a second set of BIOS programs; and storing inthe non-redundant portion of the EEPROM the operating system drivers.22. The method of storing operating system drivers as defined in claim21 wherein the first set of BIOS programs and the second set of BIOSprograms are substantially the same.